在軟體開發中，我們已經能把規格文件、架構背景與既有程式碼餵給AI，讓它協助梳理設計、生成實作，甚至撰寫測試。但隨著AI產出程式碼的速度遠超以往，一個根本問題浮上檯面：

身為開發者，我們究竟還需要懂什麼？

AI能分析規格、提出方案，也能產出可執行的程式碼，但不會替系統的成敗負責。
身為工程師，我們依然要面對開發中必須做出的判斷：

• 實作符合規格，但接上既有流程與資料後，原本的行為還成立嗎？
• 當多個請求同時修改同一筆資料，結果是否仍然正確？
• 正常流程暢通無阻，但連線逾時、網路不穩或下游服務故障時，系統是否有適當的容錯與降級能力？

我們對系統運作與業務脈絡理解得越深，就越能提供明確的背景與限制，並衡量AI提出的不同方案各有哪些代價。這正是我想透過這個系列，重新梳理軟體開發觀念與判斷的原因。

這個系列預計用至少30天（希望可以順利完賽！），沿著軟體從需求到維護的過程，整理開發者仍然需要懂的事：

需求與問題：我們究竟在替誰解決什麼困難？
程式與設計：如何讓規則、責任與介面清楚可理解？
資料與狀態：如何讓資料保留業務意思，並處理重複請求與資料不同步？
測試與安全：如何確認功能與修正真的有效，並確保只有具備權限的人能存取資料與執行操作？
部署與營運：軟體上線後，如何觀察運作狀況、處理故障與恢復服務？
協作與維護：如何讓修改有依據，讓接手的人理解我們的決定？

我會從實際開發情境出發。在規格已經完整、AI也能依規格實作的前提下，整理遇到一個需求、採用某項技術，或看到一種架構設計時，還需要先想到的幾件事：它適用的前提是什麼？會影響哪些流程？有哪些代價？要怎麼確認結果符合需求？技術細節會交代到足以理解問題與取捨，不會逐一展開成完整的實作教學。希望讀完之後，我們能更有依據地與AI討論方案，看出不必要的設計，也找得到需要繼續確認的地方。

帶著自己的經驗，一起重新思考

閱讀這個系列時，你可以帶入自己正在開發或維護的系統，想想：

• 當初為什麼這樣設計？哪些限制現在仍然成立？
• 如果AI提出另一種做法，我們會根據什麼接受或否決？

每篇文章不一定都有唯一的答案，但希望能讓我們在面對下一個需求、下一次設計討論時，多一點判斷的依據。

在壓線的最後一刻按下報名，純粹是因為最近工作真的太「充實」
每天都在救火、開會與衡量各種技術債，題目想了又刪、刪了又想

身邊朋友問我：「AI都能寫出八成程式碼了，你下班不休息，還想連續花30天寫文章???」
我想了想回答：「大概是因為……半夜連線池被打爆時，AI可以陪我一起看Log，但被老闆Call起床的還是我吧。」

玩笑歸玩笑，趁這個機會，把這幾年思考架構、檢查AI提出的方案，以及做取捨的經驗整理下來，也算是替自己留一份紀錄。
畢竟，AI輸出到一半可以停在Max tokens reached...
工程師處理到一半，也不好跟老闆說今天的token用完了對吧！

三十天說長還真的很長，立個flag：希望今年順利完賽，中途不要斷更。大家明天見！